Opacifier for detergent formulations

ABSTRACT

A fabric care formulation is provided, comprising: a liquid carrier; and a plurality of composite opacifier particles, wherein the composite opacifier particles comprise metal oxide particles that are partially or completely encapsulated by a wax; wherein the metal oxide particles are selected from the group consisting of zinc oxide, titanium oxide and mixtures thereof; wherein the metal oxide particles have a z average particle size of &gt;100 nm as measured by dynamic light scattering; wherein the wax has a melting point temperature of 45 to 110° C.; and wherein the composite opacifier particles have a z average particle size of &gt;100 nm to 2,000 nm as measured by dynamic light scattering.

CROSS-REFERENCE TO RELATED APPLICATION

This application is filed under the Patent Cooperation Treaty and claimspriority to U.S. patent application Ser. No. 16/692,941, filed 22 Nov.2019, entitled “Developer Independent Resource Based MultithreadingModule,” the contents of which are hereby incorporated by referenceherein in its entirety.

TECHNICAL FIELD

The technology described herein generally relates to use of a resourcebased multithreading module in conjunction with a single event loopruntime environment to fulfill user requests.

BACKGROUND

Many interfaces, such as websites and mobile applications, are developedfor execution in a single event loop runtime environment, in which onerequest is executed at a time. For example, a website developed forexecution in a single event loop runtime environment may include acurrency conversion calculator. A user can enter numbers into thecalculator and press an “=” button to receive a result. When the userpresses the “=” button, a request is executed in the single event loopruntime environment to perform the currency conversion the userpreviously entered into the calculator. Performing the currencyconversion will likely include an operation to access a source (such asan official database) of information on current exchange rates. Whilethe request is executed (i.e., the network accesses the current exchangerates), no other requests can be executed because of the single eventloop. This means that while a user may attempt to scroll, click otherlinks, or enter text, the website remains “frozen” until the networkaccesses the exchange rates and the calculation is completed. Once thecalculation is completed, other requests that the user makes of thewebsite are executed.

The phenomenon of one task appearing to freeze or render a website orapplication unresponsive is called blocking. To handle the problem ofblocking, many single event loop runtime environments use asynchronouscallbacks. In runtime environments with asynchronous callbacks,operations and requests are labeled either for immediate execution or asan event callback. The runtime environment generally labels operationsas event callbacks without additional input or structuring from theprogrammer. When an operation labeled as an event callback reaches thepoint of execution, it is allocated to another location to process.While the callback is processing, other immediate execution operationscan be executed and other callbacks can be allocated for processing.When a callback is processed, it is returned to the event loop forexecution. This structure means that more than one request can behandled by a single event loop.

In the example of the currency calculator website, the operation toaccess current exchange rates can be handled as a callback so that whilethe network is accessing exchange rates, the user can continue to useother features on the website. Perhaps more importantly, other usersusing the same website can use all features of the website withoutwaiting for the first user's request to complete. The asynchronouscallback structure means that applications and websites are easy toscale vertically (to handle requests from more users) using single eventloop runtime environments. Without asynchronous callbacks, a programmeror developer generally uses additional data structures to handlerequests from multiple users, which can become cumbersome as requestsare received from more users.

Currently, asynchronous callbacks are available for tasks which are I/Ointensive, such as making requests over a network. Tasks that may use alarge amount of computing resources, such as large or complexcalculations, are labeled as immediate execution and may still causeblocking, making websites and applications appear unresponsive.Accordingly, developers use technical knowledge to structure code toavoid blocking and single event loop runtime environments, which providesimple vertical scaling, are difficult to employ with simplifiedprogramming interfaces intended for novice developers, such as graphicalprogramming interfaces.

SUMMARY

A method for execution of application code developed using a simplifiedprogramming interface is provided. I/O tasks and processing intensivetasks are designated as event callbacks in a single event loop runtimeenvironment. The I/O tasks and processing intensive tasks are generatedin association with a user request. Tasks associated with eventcallbacks are offloaded to a task queue including I/O tasks andprocessing intensive tasks for execution using a resource basedmultithreading module to allocate the tasks between a plurality ofprocessors based on the current utilization of each of the plurality ofprocessors and an estimation of computing resources for execution of thetasks, where the resource based multithreading module is separate fromthe single event loop runtime environment. The tasks are executed at theallocated processors of the plurality of processors and the user requestis fulfilled using results of the executed tasks.

The method may further include identifying the I/O tasks and theprocessing intensive tasks from a plurality of received executable tasksusing predefined task information.

In a method of any previous method, the estimation of computingresources used in execution of tasks may be generated using at leasthistorical data about execution of similar tasks.

A method of any previous method may further include reporting an actualamount of computing resources used by the allocated processors of theplurality of processors in executing the tasks and updating thehistorical data about execution of similar tasks based on the reportedactual amount of computing resources used by the allocated processors ofthe plurality of processors in executing the tasks.

In a method of any previous method, the plurality of processors may beassociated with a plurality of threads.

In a method of any previous method, offloading tasks associated with theevent callbacks for execution may further include identifying one ormore processors in the plurality of processors associated with at leastone thread that is free to execute a task and determining a currentlevel of resource use for each of the identified one or more processors.

A method of any previous method may further include, for a first task ofthe offloaded tasks, identifying available processors of the identifiedone or more processors, where the available processors have enough freeresources to execute the task based on the estimation of computingresources for execution of the task and allocating the first task to aprocessor of the available processors, where a difference between theavailable computing resources of the processor and the estimation ofcomputing resources for execution of the first task is smaller than adifference between the available computing resources of at least one ofthe other available processors and the estimation of computing resourcesfor execution of the first task.

A method of any previous method may further include, for a task of theoffloaded tasks, identifying the task as an I/O task and allocating thetask to a processor of the identified one or more processors, where theprocessor has a highest current level of computing resources of theidentified one or more processors.

A computing system for executing a task allocation agnostic applicationcode includes a plurality of processors and an application engineexecuting on the plurality of processors. The application engineincludes an interpreter configured to identify an input/output (I/O)task or a processor intensive task as an intensive task from a pluralityof tasks in the task allocation agnostic application code correspondingto a received request from a user. The identification is based on aestimation of computing resources for execution of the intensive task.The computing system also includes a runtime environment including acall stack configured to execute the tasks of the application code. Thecall stack executes a task sequentially as a task reaches an executionposition within the call stack. A resource based multithreading modulealso executes on the processors of the computing system and includes atask queue, a scheduler, and an interface. The task queue is configuredto remove the intensive task from the call stack as the intensive taskreaches the execution position. The task queue includes both I/O tasksand processor intensive tasks. The scheduler is configured to allocatethe intensive task to a processor of the plurality of processors basedon the estimation of computing resources for execution of the intensivetask and a current utilization of each of the plurality of processors.The processor executes the allocated intensive task to obtain a resultof the intensive task. The interface is configured to return the resultof the intensive task to the runtime environment. The runtimeenvironment is configured to return the result of the intensive task tothe call stack and to use the result of the intensive task in completingthe request of the user.

In a computing system of the previous computing system, the runtimeenvironment may further comprise a callback queue and an event loopconfigured to control movement of callbacks from the callback queue tothe call stack.

In a computing system of any previous computing system, the schedulermay be further configured to receive a result of the executed intensivetask from the assigned processor and return the result to the callbackqueue of the runtime environment.

A method for allocating an intensive task in an application codedeveloped using a programming interface to a processor for execution isprovided. The method is obscured from the programming interface andincludes accessing the intensive task in a task queue includinginput/output (I/O) tasks and processing intensive tasks received from aJavaScript runtime environment as a result of a received user request toexecute the application code. The method further includes determining anestimation of computing resources for execution of the intensive task.The intensive task is then allocated to one of a plurality of processorsbased on a current utilization of each of the plurality of processorsand the determined estimation of computing resources for execution ofthe intensive task. The task is processed at the allocated processor andthe processed task is returned to the JavaScript runtime environment asa callback. The JavaScript runtime environment uses the processed taskin completing the user request.

A method of the previous method may further include identifying theintensive tasks from a plurality of tasks identified from theapplication code in response to receipt of the user request.

In a method of any previous method, the code may be graphical codeincluding functional modules and connectors, where the functionalmodules and connectors are associated with underlying source code.

In a method of any previous method, at least one functional module ofthe graphical code may define one of a machine learning operation and anartificial intelligence operation.

A method of any previous method may further include returning a responseto the user request to a user device.

In a method of any previous method, the estimation of computingresources for one of the intensive tasks may be determined based onhistorical data about the execution of intensive tasks.

A method of any previous method may further include updating thehistorical about the execution of intensive tasks based on actualcomputing resources used for the task, where the processed task isreturned to the JavaScript runtime environment with an indication of theactual computing resources used for the task.

In a method of any previous method, the processor intensive task may usemore than a threshold amount of computing resources.

In addition to the exemplary aspects and embodiments described above,further aspects and embodiments will become apparent by reference to thedrawings and by study of the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a diagram of a computing system including a resourcebased multithreading module to allocate tasks received by an applicationengine and executed in a runtime environment.

FIG. 2 is a detailed block diagram of a system including a resourcebased multithreading module to allocate tasks received by an applicationengine and executed in a runtime environment to one of severalprocessors.

FIG. 3 is a diagram of a compiler, including an interpreter, compilinggraphical code for execution in a runtime environment.

FIG. 4 is a diagram of a resource based multithreading module.

FIG. 5 is a flow diagram of operations for executing an intensive taskusing a resource based multithreading module.

FIG. 6 is a flow diagram of operations for categorizing an intensivetask and estimating resourced used for executing an intensive task.

FIG. 7 is a flow diagram of operations for utilizing a resource basedmultithreading module for assigning an intensive task to a processor andexecuting the task at the assigned processor.

FIG. 8 is a simplified block diagram of a computing system that may beused in implementation of a resource based multithreading module.

DETAILED DESCRIPTION

Generally, in event driven environments, such as JavaScript, source codeis compiled and as the code is executed operations are added to a callstack. The top operation on the call stack is executed, then the nextoperation on the call stack is executed, and so on, until all operationsare executed. However, some operations may take longer to execute,preventing other operations from executing even when processingresources are available, this is known as blocking.

Asynchronous callbacks can be used to address blocking, with suchcallbacks, operations are designated as immediately executable or as anevent callback. Event callbacks are generally more complex operationsthat take longer to execute, such as a request from a network, i.e.,those that are not immediately executable. During execution, when anevent callback reaches the top of the call stack, the event callback isremoved from the call stack and submitted to a worker pool. While in theworker pool, the event callback is executed. For example, in the case ofa network request, the event callback remains in the worker pool until aresponse to the request is received from the network. When the responseis received from the network, the callback is returned to a callbackqueue. The event loop returns callbacks in the callback queue to thecall stack for processing. Continuing with the network request example,when the event loop returns the callback to the call stack, the resultof the network request may be displayed to the user when the callback isreturned to the call stack and is processed.

Advantageously, while the event callback is in the worker pool, the callstack continues to execute other operations in the call stack. This isespecially helpful when applications or websites handle requests frommultiple users because subsequent users will be able to have requestsexecuted by the call stack while the first user's request is executed inthe worker pool. Subsequent requests may also be assigned to the workerpool and their processing is controlled by the event loop, meaning thatthe application or website is more likely to handle requests “fairly”between users, rather than waiting for the first user's tasks tocomplete. Event loop structure is typically inherent in the single eventloop runtime environment, so developers do not have to use advancedprogramming techniques to ensure fair request balancing among multipleusers, allowing applications and websites to be scaled vertically in arelatively simple manner.

Current asynchronous callbacks utilized in single event loop runtimeenvironments are structured to handle I/O tasks, but are not structuredto handle CPU or processing intensive tasks, such as calculations thatuse a large amount of computing resources and may take longer toexecute. So, although I/O operations can execute in the background, CPUintensive tasks are executed as part of the execution stack and anentire application may be blocked until the CPU intensive task iscomplete. In systems with multiple processors, several processors maysit idle while one processor works intensely on a CPU intensive task andmany other tasks are waiting in a queue to be handled (althoughresources are available). Further, requests from other clients cannot beexecuted until the task completes. For applications that handle multipleclient requests, such as websites, this blocking is detrimental, slowsresponse time, and may discourage visitors and users as the website willseem slow and unresponsive at times.

Further, while current single event loop runtime environments mayinclude commands and structures to move CPU intensive tasks off of thecall stack, these commands or structures may be difficult to implementand do not include intelligent allocation of CPU intensive tasks betweenmultiple available processors. For example, a command may create childthreads to execute CPU intensive tasks. As CPU intensive tasks reach thetop of the call stack, the tasks are assigned to child threads in around-robin manner. As such, there is no intelligent allocation of tasksbased on the complexity of the task or computing resources used by thetask. This round-robin allocation can result in overloading of oneprocessor and underutilization of other processors, i.e., the entirecomputation is delayed even though resources are available. In theseinstances, certain applications, such as websites, may appearunresponsive or the like to a user, even though there is availablecompute capacity.

Available commands and structures often require knowledge about thestructure of the single event loop runtime environment to implement thecommands or structures to prevent blocking and allocate tasks in anefficient manner. Because of the knowledge required, these methods maybe incompatible with simplified programming interfaces that aim to allownovice programmers with limited knowledge to generate functional code.These methods may also be difficult for programmers using traditionalprogramming interfaces where it is more efficient and simple to createcode without considering task allocation.

In the present disclosure, a developer independent resource basedmultithreading module is used in a single event loop runtime environmenthaving an asynchronous callback structure, allowing capitalization onthe scalability of the single event loop runtime environment whileintelligently allocating CPU or processor intensive tasks to takeadvantage of multiprocessing. Further, applications including CPUintensive tasks, such as machine learning in single event loop runtimeenvironments, can be implemented in the present architecture withoutrequiring sophisticated programming knowledge because the resource basedmultithreading module works with the runtime environment to allocatetasks without additional input from the developer. The resource basedmultithreading module and single event loop runtime environment may beobscured from the developer in a simplified or traditional programminginterface so that the developer can program without considering taskallocation.

The ability to use the resource based multithreading module for taskallocation allows more developers to utilize artificial intelligencesuccessfully in large scale applications because less computing andprogramming knowledge is required to implement machine learning withoutoverburdening computing resources. Because less specialized skill isneeded to implement these applications, entities can more readilyimplement functionality into their websites and other applications,without requiring large time and monetary investment of programmers anddevelopers.

The resource based multithreading module operates in conjunction withthe single event loop runtime environment with asynchronous callbacks.Instead of pulling only I/O operations from the call stack, asconventional application programming interfaces, the resource basedmultithreading module pulls both I/O operations and CPU intensiveoperations from the call stack, so that both I/O tasks and CPU intensivetasks can execute while other operations are executed on the call stack.The resource based multithreading module places tasks pulled off of theexecution stack into a task queue to be passed to a scheduler in a firstin, first out pattern. The scheduler allocates a task to a thread withinthe multithreader execution pool. The threads within the execution poolare associated with one of a plurality of processors. The schedulerallocates tasks to a thread based on the current utilization of theprocessors in the plurality of processors with free threads and thecomputational intensity of the task.

Once a task is executed by a processor, the resource basedmultithreading module returns the result to a callback queue of theruntime environment as a callback and the thread used to execute thetask is free for tasks remaining in the task queue. When the result ofthe task is returned to the callback queue, the event loop controls whenthe callback is returned to the execution stack for execution. In thismanner, the resource based multithreading module acts to bothhorizontally and vertically scale applications, helping to maximizeutilization of compute resources and schedule tasks, allowing commandsto be executed faster on fewer resources and/or improve responsivenessfor commands with the same resources as compared to conventional threadapproaches.

As one example, the multithreading module acts as thread pool to handlethe execution of tasks in Node.js. In this example, the main threadfunction calls tasks to the shared task queue, which threads in thethread pool pull and execute. In operation the module acts to not blocksystem functions, such as networking translate to kernel-sidenon-blocking sockets, while blocking system functions such as file I/Orun in a blocking way on their own threads. When a thread in the poolcompletes a task, it informs the main thread of completion, which inturns, wakes up and executes the registered callback. In this manner,the thread pool can automatically cater to further requests withoutblocking new similar requests coming in, until a threshold of CPU or I/Oresource availability has been reached In certain instances, themultithreading module may enhance performance by 2 to 3 times ascompared to conventional architectures, while also omitting the need forthe developer to understand code performance (e.g., which requests mightblock others), allowing less skilled developers to contribute code forthe application.

FIG. 1 illustrates a diagram of a computing system 100 including aresource based multithreading module 106 to allocate tasks received byan application engine 102 and execute in a runtime environment 104.Generally, an application engine 102 receives user requests from userdevices (i.e., user devices 114, 116, 118, and 120), which may becomputers, smart phones, etc. User requests may include requests toaccess resources on a website or application, requests to interact witha website or application, and/or requests to submit information to awebsite or application. A single user request may invoke a cascade ofprogramming operations of the website or application, e.g., a request toaccess resources on a website may include operations for updating theuser interface of the website to indicate the request is beingprocessed, retrieving the resources, and displaying the resource to theuser when it is retrieved, among other operations.

User requests may be sent from a user device to the application engine102 as a hypertext transfer protocol (HTTP) request transmitted to theapplication engine 102 using transmission control protocol (TCP) andthen may be transmitted over a network to the application engine 102.The application engine 102 may be located, for example, on a serverallocated to the website or application associated with the applicationengine 102. The application engine 102 generally receives the incominguser request, compiles the machine readable code to execute the userrequest, and routes the machine readable code to the runtime environment104.

In system 100, the multithreading module 106 allocates tasks associatedwith the user request and the application engine 102 may include acompiler that categorizes tasks as intensive tasks or immediatelyexecutable tasks before passing the machine readable code to the runtimeenvironment 104. An intensive task may be, for example, an I/O intensivetask, a processor intensive task, or any other task that may not executequickly or easily and may block other user requests, causing theapplication or website to appear unresponsive or slow. Thecategorization of intensive tasks by the application engine 102 providesthe runtime environment 104 with information about tasks to execute ascall backs. Advantageously, when tasks are categorized as intensivetasks before machine readable code is passed to the runtime environment104, the runtime environment 104 may be used without modification.

In some implementations, the application engine 102 may also provide anestimation of computing resources for execution of the intensive tasks.This estimation may be used by the resource based multithreading module106 to efficiently allocate the intensive tasks among processors (e.g.,CPUs 110 and 112). The estimation may be based on resources used for thetask (e.g., whether a task uses processing power or I/O), historical useof resources for execution of similar tasks, characteristics of the taskitself, and/or other parameters. In some implementations, theapplication engine 102 may continually update historical data afterintensive tasks are executed to generate more accurate estimates for thecomputing system over time, but in other implementations, theapplication engine 102 may update historical data at set intervals(e.g., every other day, twice a week, or the like), or may be structuredto update when directed.

As the machine readable code is passed to the runtime environment 104,the code is executed like other code in the runtime environment 104.Broadly, tasks categorized as immediately executable are executed asthey reach the top of a call stack and tasks categorized as intensivetasks are offloaded to the resource based multithreading module 106 forexecution. The intensive tasks are then returned to the runtimeenvironment 104 to be executed as callbacks, even though the runtimeenvironment 104 may not be modified to handle intensive tasks ascallbacks. For example, the runtime environment 104 may be any runtimeenvironment using a single event loop and asynchronous callbacks, suchas JavaScript or node.js, where these environments are not modified tohandle the intensive tasks as callbacks, but given that these runtimeenvironments are generally simpler to use as compared to othernon-single loop environments, and can handle requests from multipleusers without additional input from the programmer.

The resource based multithreading module 106 allocates tasks categorizedas intensive tasks amongst processors. For example, in FIG. 1 , theresource based multithreading module 106 allocates intensive tasks to atleast CPU 110 and CPU 112. The resource based multithreading module 106may allocate tasks based on utilization or capacity. For example, theresource based multithreading module 106 may use an estimation ofcomputing resources required for execution of the intensive tasks whenallocating resources, helping to more evenly distribute compute capacityacross resources. In some implementations, the estimation is generatedby the application engine 102 and received along with the intensivetasks, e.g., as tagged data, or the like, in other implementations, theestimation is generated by the resource based multithreading module 106,or otherwise determined.

Intensive tasks are queued when they reach the resource basedmultithreading module 106 and when an intensive task reaches the frontor top of the queue, the resource based multithreading module 106evaluates the estimated computing resources required for the task, alongwith the current utilization of processors available for processing thetask. The resource based multithreading module 106 then assigns theintensive task to a processor that is both free (or at least morecapacity than other resources) to execute a new task and computingresources available to execute the particular intensive task. Where twoor more processors meet the above criteria, the resource basedmultithreading module 106 may assign the task to the processor with themost availability.

By allocating tasks based on availability and estimated time, the system100 can better utilize the capabilities and capacities of multipleprocessor hardware structures. As an example, a thread pool includingsix threads where three threads are associated with the CPU 110 andthree threads are associated with the CPU 112, in conventionalround-robin task allocation, tasks are assigned to the next availablethread as tasks reach the front of a task assignment queue Accordingly,all of the threads associated with, for example CPU 112 may be busy withI/O tasks using a relatively small amount of resources, leaving CPU 112with excess capacity. In contrast, two threads associated with CPU 110may be busy with processor intensive tasks, utilizing the full capacityof the CPU 110. Meanwhile, CPU 112 is underutilized from a processingperspective.

On the contrary, with the same six threads, using the resource basedmultithreading module 106, a scheduler considers the capacity andcurrent utilization of both CPU 110 and CPU 112 when allocating tasks.In an example, CPU 112 has one free thread and two threads occupied withI/O intensive tasks while CPU 110 has two free threads and one threadoccupied with a processing intensive task. In the round-robin allocationdescribed above, the processing intensive task may be assigned to theCPU 110 because the CPU 110 is next in line to handle a new task,resulting in the underutilization. Here, the scheduler assigns theprocessor intensive task to the CPU 112, taking advantage of theprocessing capability of the CPU 112. The CPU 110 still has free threadsfor other I/O intensive and processing intensive tasks, such thatwebsites and applications can more effectively horizontally scale byadding additional processors, even when executing a runtime environmentwith a single event loop for simple vertical scaling. Resource basedallocation also helps to fully utilize existing processing resources,such that additional processing resources do not need to be added to asystem to still experience an increased performance, e.g., increasedresponsiveness, for a given application or website including themultithreading module 106.

After task execution by the CPU 110 or the CPU 112, the result of thetask is returned to the resource based multithreading module 106, whichreturns the result to a callback queue in the runtime environment 104.The event loop of the runtime environment 104 may operate conventionallyto move the callbacks to the stack to execute in the runtime environment104. Once all tasks associated with a user request are executed withinthe runtime environment 104, the runtime environment 104 returns anoutput for the request to the application 102, returning the output tothe user device where the request originated. When the runtimeenvironment 104 receives the result of a task to execute as a callback,the runtime environment 104 treats the callback like any other callbackexecuted within the runtime environment 104, i.e., does not havevisibility to the allocation threading implemented by the module 106.

FIG. 2 is a detailed block diagram of a system including a resourcebased multithreading module 206 to allocate tasks received by anapplication engine 202 and executed in a runtime environment 204 to oneof several processors. The application engine 202 receives a requestfrom a user and recalls code 222 associated with the received request,as some examples, the code 222 may be JavaScript source code, graphicalcode with associated source code, or the like. The code 222 is relayedto a compiler 224 in the application engine 202 for execution. In thesystem shown in FIG. 2 , the compiler 224 includes an interpreter 226that identifies tasks within the code 222 and categorizes the tasks intoimmediately executable tasks (e.g., simple, quick tasks) and intensivetasks (e.g., demanding, long, complicated tasks). Intensive tasks areexecuted as callbacks and are usually I/O intensive and/or processorintensive tasks. During compilation of the code 222, the compilerindicates tasks to execute as callbacks in a conventional method for theruntime environment 204.

The interpreter 226 may also estimate computing resources or computetime for executing intensive tasks. For example, the interpreter 226 mayuse data indicating computing resources used in executing the samefunctions in the past. This data may be continually updated as thecomputing system processes user requests, leading to more accurateestimations of computing resources over time. Additionally oralternatively, the interpreter 226 may use interpolation or otherestimation methods to estimate based on inputs and parameters of thefunction in the code 222. This estimation may then be associated with anoperation when the operation is passed to the runtime environment 204.Generally, the estimation will not affect how the runtime environment204 executes a task, but rather the estimation remains with the task andis used by the resource based multithreading module 206 to allocate thetask to a processor.

When a request is passed to the runtime environment 204, tasksassociated with the request are added to a call stack 228 of the runtimeenvironment. Immediately executable tasks are executed by the runtimeenvironment when the task reaches the top of the call stack 228. When anintensive task reaches the top of the call stack 228, the intensive taskis removed from the call stack 228 and passed to the resource basedmultithreading module 206 for allocation to a processor for execution.The runtime environment 204 maybe configured to handle immediatelyexecutable tasks and callbacks in this manner such that the runtimeenvironment 204 does not need to be modified to process intensive tasksin conjunction with the resource based multithreading module 206.

A scheduler 234 allocates tasks to processors in a processing pool 208.The scheduler 234 may be configured to access the estimation ofcomputing resources for executing the task generated by the interpreter226. In other implementations, the estimation of computing resources forexecuting the task may be generated by the scheduler 234.

The scheduler 234 monitors a thread pool including threads associatedwith processors in the processor pool 208. For example, as shown in FIG.2 , a CPU 248 is associated with threads 236 and 238, a CPU 250 isassociated with threads 240 and 242, and a CPU 252 is associated withthreads 244 and 246. In other implementations, the processor pool 208may include fewer or more processors. Further, the processors in theprocessor pool may be associated with fewer or more threads, dependingon how the processor is configured to handle tasks in parallel. Bymonitoring the thread pool, the scheduler 234 tracks which threads areavailable to execute tasks and which threads are busy.

The scheduler 234 also monitors or receives input regarding theutilization of CPUs 248, 250 from a resource perspective. When a newintensive task is received by the scheduler 234, the scheduler 234 usesone or more of the following parameters: the estimation of processingresources required for execution, status of threads in the thread pool,and current utilization of the CPUs 248, 250, and 252 to allocate thetask to a CPU with a free thread, and/or resources to complete theintensive task. In some implementations, the scheduler 234 may usedifferent logic in allocating I/O intensive tasks and processorintensive tasks. For example, a processor intensive task may beallocated to a CPU with a free thread and a low processor utilizationrelative to other CPUs in the processing pool 208. An I/O intensivetask, in contrast, may be allocated to a CPU with a free thread and ahigh processor utilization relative to other CPUs in the processingpool. This logic allows CPUs engaged in processor intensive tasks totake on additional I/O tasks, which require fewer processing resources,as those CPUs have capacity to do so. This leaves threads associatedwith CPUs having more capacity to handle processor intensive tasks thatmay be queued for processing, such that each CPU is as fully utilized aspossible. With this structure, the scheduler 234 is unlikely to have towait for a free thread associated with a CPU with available capacity asprocessor intensive tasks come up in a queue for allocation.

In the example shown in FIG. 2 , the scheduler 234 has allocated a taskto the thread 242 associated with the CPU 250. The CPU 250 executes thetask and the thread 242 returns the result to the runtime environment204. The thread 242 is then returned to the resource basedmultithreading module as a thread available for execution of anotherintensive task. The thread 242 returns the result of the task to theruntime environment 204 as an event callback. The event callback isplaced in a callback queue 230 within the runtime environment 204. Theevent loop 232 controls when event callbacks in the callback queue arereturned to the call stack 228 for execution, where the event loop 232is generally configured to handle callbacks in the this manner.

Once the event loop 232 moves an event callback to the call stack 228,the event callback is executed. In many instances, the execution of theevent callback means that other functions or operations use the resultof the event callback to return a result of the user's request to theuser. In some instances, the execution of the event callback returns theresult directly to the user.

FIG. 3 is a diagram of a compiler 324, including an interpreter 326,compiling graphical code 354 for execution in a runtime environment 304.As discussed above, the compiler 324 may be configured to compiletraditional source code and/or graphical code, such as the graphicalcode 354, generated using a graphical coding user interface, such as thegraphical coding interface described in U.S. Provisional PatentApplication 62/897,490 entitled “Modular Machine Learning and ArtificialIntelligence,” which disclosure in incorporated herein. Graphical codingmay be a user friendly method of coding websites and applications. Forexample, the graphical code 354 includes functionality modules (i.e.,functionality module 356) connected by connectors (i.e., connector 358).A graphical coding interface may allow a user to drag and drop functionsand connect functions to create code to generate a desired result.Graphical coding typically may require less training and knowledge thantraditional coding, opening development up to a larger group of users.However, this larger group of users may not have in-depth knowledge oftask allocation, leading to development of websites and applicationsthat run slowly due to blocking issues. Implementing a resource basedmultithreading module, such as ones described here, in conjunction witha graphical coding interface allows less experienced developers to buildwebsites and applications that execute more efficiently, withoutadditional knowledge or input as to task allocation and higher levelprogramming concepts.

For example, in graphical code 354, the functionality modules include aninput, a functionality, and an output. The functionality may includeartificial intelligence or machine learning functions, which can bedifficult to program when writing source code from scratch. Because ofthe ease of generating the graphical code 354, more developers mayimplement artificial intelligence or machine learning functions intowebsites or application. However, these artificial intelligence andmachine learning functions often include processor intensive tasks thatare prone to causing blocking in single event loop runtime environments.When the compiler 324 and the interpreter 326 are configured to compilegraphical code including these functions such that a resource basedmultithreading module 306 can be used to allocate the processorintensive tasks, blocking is less likely to occur. Accordingly,developers can insert functionality modules for artificial intelligenceor machine learning in a simplified programming interface with lessconcern about how the website or application will ultimately perform.

The functionality modules and connectors that form the graphical code354 are associated with underlying source code. When the graphical code354 is compiled by the compiler 324 in response to a user request, thecompiler uses the underlying source code for the functionality modulesand connectors to generate machine readable code to execute in theruntime environment 304. The compiler 324 includes the interpreter 326.In the implementation shown in FIG. 3 , the interpreter 326 uses taskdata 360 to categorize tasks in the graphical code 352 as immediatelyexecutable tasks or intensive tasks and multithreading data 362 togenerate an estimate of computing resources for intensive tasks.

In some implementations, the task data 360 and the multithreading data362 may be stored locally on a computing system used to execute thegraphical code 354. In other implementations, the interpreter 326 mayaccess the task data 360 and the multithreading data 362 stored in aremote location, such as a cloud storage location. Generally the taskdata 360 includes information about which tasks should be categorized asimmediately executable and which tasks are intensive tasks. For example,the task data 360 may be a list of possible functions executable in theruntime environment 304 and whether tasks associated with the functionsare immediately executable or are intensive tasks. In someimplementations, the task data 360 may be a list of functions associatedwith intensive tasks. Further, in some implementations, in lieu ofaccessing task data 360, functions in the graphical code 354 may beassociated with an indication that the task is an intensive task.

The multithreading data 362 provides data for the interpreter 326, whichcan be used to estimate computing resources for executing intensivetasks. For example, the multithreading data 362 may include actualcomputing resources used in executing tasks previously or historically.A task may include both a function and the input to the function. Theinterpreter 326 may view or receive data regarding the actual computingresources used to execute the same function in the past. When thefunction was executed with the same input, the interpreter 326 maydetermine that the required computational resources will be the same asthose used to execute the task previously. When the function wasexecuted with different input, the interpreter 326 may useinterpolation, machine learning, or other estimation methods to providean estimate of computing resources to execute the task, or may assumethat the input may be generally the same and use previously executeddata. In some implementations, the multithreading data 362 iscontinuously updated as new tasks are executed in the runtimeenvironment 304.

The compiler 324 creates machine readable code for execution in theruntime environment 304. The runtime environment 304 uses thecategorization of tasks generated by the interpreter 326 using the taskdata 360 to determine how the tasks are executed. Generally, taskscategorized as intensive tasks are offloaded to the resource basedmultithreading module 306 for execution. The resource basedmultithreading module 306 uses the estimation of resources used toexecute intensive tasks to allocate the offloaded intensive tasks to aprocessor for execution.

FIG. 4 is a diagram of a resource based multithreading module 406. Whenthe resource based multithreading module 406 receives an offloadedintensive task from a runtime environment, the task is added to a taskassignment queue 464. Tasks are added to the task assignment queue 464and are generally passed to a scheduler 434 in the order the tasks arereceived by the resource based multithreading module. For example, inFIG. 4 , task 466 is the next task passed to the scheduler 434 forallocation. Once task 466 is allocated, tasks 468, 470, and 472 arepassed to the scheduler 434, in turn. In some instances, tasks 468, 470,or 472 may be allocated before task 466 is allocated because resourcesare available to execute task 468, 470, or 472 before resources areavailable to execute the task 466.

The scheduler 434 assigns tasks to threads in the resource basedmultithreading module 406. The threads are each associated with acomputing resource, such as a CPU. For example, in FIG. 4 , threads 436,437, and 438 are associated with the CPU 448. Threads 440, 441, and 442are associated with the CPU 450. Threads 444, 445, and 446 areassociated with the CPU 452.

When the scheduler 434 receives an intensive task, the scheduler firstdetermines available threads for execution of a new task. In FIG. 4 ,threads that are not available for execution of a new task are shownwith a broken outline. Generally, when a thread is in use for a task, itcannot be assigned another task. As such, when all threads associatedwith a CPU are busy, such as threads 444, 445, and 446, the associatedCPU 452 does not have a thread free for execution of a new task,regardless of the utilization of the associated CPU 452. In FIG. 4 ,both thread 442 and thread 437 are available for execution of a newtask.

The scheduler 434 determines the current utilization of the CPUs 448 and450 associated with the free threads 437 and 442, respectively, even ifthe tasks are processor or I/O intensive tasks. Because a goal of thescheduler 434 is to fully utilize the CPUs 448, 450, and 452, while alsomoving tasks through the task assignment queue 464 as fast as possible,the scheduler 434 uses different logic to allocate I/O intensive tasksand processor intensive tasks. Accordingly, the scheduler 434 mayadditionally categorize an intensive task as an I/O intensive task or aprocessor intensive task by using a list of known I/O tasks. In someinstances, one of the CPUs 448, 450, and 450 may be dedicated to I/Ointensive tasks such that all tasks that are identified as I/O intensivetasks are allocated to the dedicated CPU.

In another example, with I/O intensive tasks, the scheduler 434 mayallocate the task to a CPU with a free thread, with an aim to maintaincomputing resources available for processor intensive tasks. In theexample shown in FIG. 4 , an I/O intensive task would likely beallocated to thread 437 to be executed on the CPU 448. This means thatif, for example, if the next task in the queue is processor intensive,the CPU 450 could still handle execution. If the scheduler 434 allocatedan I/O intensive task to thread 442 to be executed on the CPU 450, theCPU 450 would have no free threads available, but would still have alarge amount of available processing resources available, which would bea poor utilization of compute resources. In these instances, if aprocessing intensive task were then passed to the scheduler 434, thetask may be too large to execute on the CPU 448, leaving a waitingperiod while the scheduler 434 waits for a thread to open up on a CPUwith the processing capacity to execute the processing intensive task.

With processor intensive tasks, the scheduler 434 determines a CPU withboth a free thread and the processing resources available to execute thetask. For example, in FIG. 4 , threads 437 and 442 are available.However, the CPU 448 is 60% utilized, meaning it could likely not handleanother processing intensive task without becoming over utilized, butthe CPU 450 is 30% utilized and could likely comfortably take on anotherprocessor intensive task, without becoming overburdened, so thescheduler allocates the task to thread 442 to be executed by the CPU450.

Where several CPUs are available with a free thread and sufficientresources to execute a processor intensive task, the scheduler 434 mayallocate further based on the estimation of computing resources used toexecute the task. For example, if a task is estimated to use an amountof resources roughly equivalent to 20% utilization of either the CPU 448or the CPU 450 and the CPU 448 is at 40% utilization while the CPU 450is at 50% utilization. Either the CPU 448 or the CPU 450 have sufficientresources to handle the task. In some implementations, the task may beassigned to the thread 442 for execution on the CPU 450 to leave thelarger resources available on the CPU 448 available for other tasks. Inother implementations, the task may be assigned to the thread 437 toexecute on the CPU 448 to provide a buffer in case the estimation isincorrect. This portion of the logic of the scheduler 434 may beadjusted depending on the needs and goals of a system. For example, asystem handling large numbers of processor intensive tasks may allocateso that there are more resources available for further processorintensive tasks. In contrast, a system that is performing highlycritical functions, such as functions associated with emergencyresponse, may assign tasks to ensure that there are always sufficientresources to execute the current task, even if the estimation is lowerthan the amount of resources a task actually takes.

After the task is executed, the result is returned to a runtimeenvironment for execution as a callback. The thread assigned to the taskis then free to complete a new task and the utilization of theassociated CPU is updated to reflect that the task is complete. Theruntime environment executes the callback with other callbacks andimmediately executable tasks to fulfill the user request that firstgenerated the tasks.

FIG. 5 is a flow diagram of operations 500 for executing an intensivetask using a resource based multithreading module 406. A receivingoperation 502 receives a request to execute application code. Thereceived request may originate from a user device accessing a website orusing an application. User devices may include, for example and withoutlimitation, personal computers, smart phones, tablets, wearable smartdevices such as activity trackers or smart watches, and voice activatedsmart hubs. For example, when a user selects a button on a website toretrieve a file, the selection of the button is received by thereceiving operation 502 as a request to execute code associated with,for example, the appearance of the user interface when the button isdepressed, accessing the file, formatting the file for display to theuser, etc. In some implementations, the application code is conventionalsource code. The conventional source code may be a task allocationagnostic code, meaning that the code does not include specializedstructures, commands, or other strategies for allocating tasks of thecode for efficient execution of the code.

In other implementations, the application code may be developed using,for example, a graphical programming interface (or other simplifiedprogramming interface) to generate graphical code. Graphical code mayinclude functionality modules connected to form a program orapplication. The functionality modules and connectors may be associatedwith underlying conventional source code. In other implementations, acompiler may be configured to receive graphical code and directlycompile the graphical code without first translating graphical code toconventional source code.

An identification operation 504 identifies one or more executable taskswithin the application code. An executable task includes a function andan input to the function. When the application code is received asconventional source code, the identification operation 504 identifiesexecutable tasks as determined by the runtime environment. When theapplication code is developed by a graphical programming interface,functionality modules and connectors of the graphical code may beassociated with pre-defined executable tasks or functions usable in theidentification operation 504 to identify executable tasks.

A categorizing operation 506 categorizes at least one of the one or moreexecutable tasks within the application code as an intensive task.Intensive tasks may include processor intensive tasks, I/O intensivetasks, or both. The categorization may be based on data indicatingfunctions associated with intensive or otherwise resource heavy tasks.For example, the categorization operation 506 may access a list offunctions generally used to implement intensive tasks. When one of thefunctions is called, the resulting task is identified as an intensivetask.

The categorization may be based on an estimate of computationalresources utilized for execution of the intensive task usingmultithreading data. Multithreading data may be data indicatingprocessing resources used in execution of similar tasks by the samecomputing system. The estimate may be generated using, for example, amachine learning module relying on the multithreading data.Computational resources may be defined in terms of processing resourcesand/or in terms of time to execute the task. Tasks that use morecomputational resources (e.g., take a long time to execute or use alarge amount of processing power) are identified as intensive tasks.Intensive tasks may be defined as tasks that take more than a thresholdamount of computing resources or take longer than a threshold amount oftime to execute.

Generally, the intensive tasks are sent, along with the other identifiedexecutable tasks, to a single event loop runtime environment utilizingasynchronous callbacks. In the runtime environment, executable tasksthat are not intensive tasks are generally executed upon reaching anexecution position in a call stack in the runtime environment. Incontrast, intensive tasks are offloaded upon reaching an executionposition in the call stack. Instead of directly executing the task, aplacing operation 508 places the at least one intensive task into a taskallocation queue of intensive tasks. The task allocation queue ofintensive tasks is located outside of the runtime environment.

An assigning operation 510 assigns the at least one intensive task inthe task allocation queue to one of a plurality of processors based onan estimation of computational resources for execution of the intensivetask and current utilization of each of the plurality of processors.Where the estimation of computation resources for execution of theintensive task is used for categorization of an executable task as anintensive task, the same estimation may be utilized in assigning theintensive task to a processor. In other implementations, the estimationmay be generated in a similar manner prior to the assigning operation510.

Generally, the assigning operation 510 occurs by assigning an intensivetask to a thread associated with a processor in a plurality ofprocessors. The assigning operation 510 may further analyze whichprocessors in the plurality of processors have at least one thread freefor execution of a task. A current utilization is then determined foreach of the processors with at least one free thread. The assigningoperation 510 then uses the current utilization and the estimation ofcomputation resources used to execute the intensive task to assign theintensive task to a processor. In some implementations, the assigningoperation may attempt to assign the intensive task to a processor withavailable resources most closely matching the estimation of resources toexecute the intensive task. For both processor intensive tasks and I/Ointensive tasks, this method ensures that there are enough resources toexecute the task while optimizing utilization of individual processorsin the plurality of processors. Once an intensive task is assigned to aprocessor, the processor executes the task.

A returning operation 512 returns a result of the intensive task to acallback queue, where the result of the intensive task is associatedwith an indication of the amount of processing resources used inexecuting the intensive task. The callback queue is generally astructure within the runtime environment. The task is moved to the callstack by the event loop within the runtime environment. Upon reachingthe execution position in the call stack, the result of the task is usedin fulfilling the user request. For example, where the result of theintensive task provides input for a subsequent task, the subsequent taskmay be executed. For example, a resource may be formatted to return tothe user or the result of a machine learning operation may be used in asubsequent calculation.

Further, upon reaching the execution position in the call stack, theindication of the amount of processing resources used in executing theintensive task is returned to the multithreading data, which isgenerally located outside of the runtime environment. An updatingoperation 514 then updates the multithreading data based on theindication of the amount of processing resources used in executing theintensive task. Accordingly, over time, the multithreading data is morecomplete and more accurate estimations of computing resources can begenerated. When the estimations are more accurate, intensive tasks areless likely to cause overutilization or underutilization of processorswithin a plurality of processors.

FIG. 6 is a flow diagram of operations for categorizing an intensivetask and estimating resourced used for executing an intensive task. Areceiving operation 602 receives a request to execute application code.As described above with respect to FIG. 5 , application code may beconventional source code or graphical source code. The request toexecute the application code may be received in response to a useraction. For example, the user may interact with an application through asmart hub device and may generate the request to execute the applicationcode by verbally asking the smart hub device to perform an actionassociated with the application.

An identifying operation 604 identifies, during compilation of theapplication code, one or more executable tasks within the applicationcode. The identification of one or more executable tasks within theapplication is similar to the identifying operation 504, discussedabove. A categorizing operation 606 categorizes each of the one or moreexecutable tasks as an immediately executable task or as in intensivetask based on predefined information about intensive tasks. For example,the predefined information about intensive tasks may be a list offunctions that generate intensive tasks. If an identified executabletask calls a function on the list, the categorizing operation 606categorizes the task as an intensive task. In other implementations, thepredefined information about intensive tasks may be an indication, inthe code of the intensive task, that the task is intensive.

An estimation operation 608 estimates, for at least one intensive task,an amount of computing resources for execution of the intensive taskbased on multithreading data for the intensive task. The multithreadingdata may be a machine learning module relying on historical data aboutcomputing resources used for execution of similar intensive tasks. Forexample, the historical data may include computing resources used inexecution of functions associated with intensive tasks. The machinelearning module may consider computing resources used to execute thesame function with different inputs and computing resources used toexecute similar functions with similar inputs in generating theestimation.

An exporting operation 610 exports machine readable code, where each ofthe one or more executable tasks is associated with an indication of thecategorization of the task and the at least one intensive task isassociated with the estimation. The indication of the categorization ofthe task is used by a runtime environment in execution of the task.Instead of executing intensive tasks as the intensive tasks reach anexecution position in the call stack of the runtime environment, theintensive tasks are popped off of the stack and executed as callbacksusing a resource based multithreading module.

When the intensive task is popped off of the stack and offloaded to theresource based multithreading module, the estimation of resources toexecute the task is used to allocate the task to a processor. Forexample, the resource based multithreading module may allocate executionof the intensive task to a processor with available resources exceedingthe estimation of resources to execute the task. The processor thenexecutes the task and returns the result of the execution to the runtimeenvironment. The processor also returns the amount of computingresources actually used in execution of the intensive task. An updatingoperation 612 updates the estimation data for the at least one intensivetask based on information about the amount of resources actually used inexecution of the at least one intensive task, where the information isreceived after execution of the at least one intensive task. Forexample, the updating operation 612 may occur when the task is returnedto a call stack as a callback and is executed in the runtimeenvironment.

FIG. 7 is a flow diagram of operations for utilizing a resource basedmultithreading module for assigning an intensive task to a processor andexecuting the task at the assigned processor. A receiving operation 702receives an intensive task from a call stack. The intensive task isoffloaded from call stack of a runtime environment.

A determining operation 704 determines an estimated amount of computingresources for execution of the intensive task. The determining operation704 may be similar to the estimation operation 608, using a machinelearning module relying on estimation data to generate the estimatedamount of computing resources for execution of the intensive task. Inother implementations, the estimations may be predefined for functionsassociated with intensive tasks. For example, a function performing acalculation may be associated with a specific amount of computingresources dependent on the input such that the estimation may begenerated based on a formula for the function. The formula may beupdated over time using a machine learning module and data about theactual computing resources used in executing a task. This method isuseful for some processor intensive functions where the computingresources used in executing a task is highly dependent on the input tothe functions. Some functions, such as I/O functions, may have apredefined estimate of the amount of resources used in executing thefunction regardless of the inputs to the function.

An identifying operation 706 identifies one or more processors in aplurality of processors associated with at least one thread free forexecution of a task. Generally, the plurality of processors are eachassociated with one or more threads in a thread pool. When all of thethreads associated with a particular processor are busy executing atask, the processor cannot be used to execute additional tasks until athread associated with the processor completes a task.

A determining operation 708 determines the current utilization of theone or more identified processors associated with at least one threadfree for execution of a task. The current utilization of the one or moreidentified processors may be requested by the resource basedmultithreading module in response to the identifying operation 706. Inother implementations, the resource based multithreading module maycontinuously monitor utilization of all processors associated withthreads in the thread pool.

An assigning operation 710 assigns the intensive task to one of the oneor more identified processors based on the estimation of the amount ofcomputing resources for execution of the intensive task and the currentutilization of the one or more identified processors. The assigningoperation 710 may identify available processors based on a comparison ofthe estimation of the amount of computing resources for execution of theintensive task with the current utilization of the identifiedprocessors. An available processor may be defined as a processor withmore computing resources available than the estimation of computingresources for execution of the intensive task. In some implementations,the assigning operation 710 may identify the available processor with anamount of available computing resources most closely matching theestimation of computing resources for execution of the intensive task.This method means that the assigned processor is as close to fullyutilized as possible and that close to a maximum amount of computingresources are available for execution of other intensive tasks.

An executing operation 712 executes, at the assigned processor, theintensive task. A returning operation 714 returns the result of theexecuted intensive task to a callback queue, where the result isassociated with an indicator of computing resources actually used inexecution of the intensive task. The indicator of computing resourcesactually used in execution of the intensive task may be used to updateestimation data used by a machine learning module in the determiningoperation 704. The indicator of computing resources actually used mayalso be used in a machine learning module to update the estimationformula associated with a function, discussed in the determiningoperation 704.

FIG. 8 illustrates a simplified block diagram for the various devices ofthe system. As shown, the various devices may include one or moreprocessing elements 802, a display 806, one or more memory components808, a network interface 810, and external devices 812, where thevarious components may be in direct or indirect communication with oneanother, such as via one or more system buses, contract traces, wiring,or via wireless mechanisms.

The one or more processing elements 802 may be substantially anyelectronic device capable of processing, receiving, and/or transmittinginstructions. For example, the processing elements 802 may be amicroprocessor, microcomputer, graphics processing unit, or the like. Italso should be noted that the processing elements 802 may include one ormore processing elements or modules that may or may not be incommunication with one another. For example, a first processing elementmay control a first set of components of the computing device and asecond processing element may control a second set of components of thecomputing device where the first and second processing elements may ormay not be in communication with each other. Relatedly, the processingelements may be configured to execute one or more instructions inparallel locally, and/or across the network, such as through cloudcomputing resources.

The display 806 is optional and provides an input/output mechanism forthe computing devices, such as to display visual information (e.g.,images, graphical user interfaces, videos, notifications, and the like)to the user, and in certain instances may also act to receive user input(e.g., via a touch screen or the like). The display may be a liquidcrystal display screen, plasma screen, light emitting diode screen, anorganic liquid emitting diode screen, or the like. The type and numberof display may vary with the type of devices (e.g., smartphone versus adesktop computer).

The memory components 808 store electronic data that may be utilized bythe computing devices, such as audio files, video files, document files,programming instructions, and the like. The memory components 808 maybe, for example, non-volatile storage, a magnetic storage medium,optical storage medium, magneto-optical storage medium, read onlymemory, random access memory, erasable programmable memory, flashmemory, or a combination of one or more types of memory components. Inmany embodiments, the servers 102, 106 may have a larger memory capacitythan the computing devices 104, 108, with the memory componentsoptionally linked via a cloud network or the like.

The network interface 810 receives and transmits data to and from anetwork to the various computing devices 114, 116, 118, 120 and otherdevices, such as servers. The network/communication interface 810 maytransmit and send data to the network directly or indirectly. Forexample, the networking/communication interface may transmit data to andfrom other computing devices through the network which may be acellular, satellite, or other wireless network (WiFi, WiMAX, Bluetooth)or a wired network (Ethernet), or a combination thereof. In someembodiments, the network interface may also include various modules,such as an API that interfaces and translates requests across thenetwork to the specific local computing elements for the variouscomputing devices 114, 116, 118, 120.

The various computing devices and/or servers 114, 116, 118, 120 may alsoinclude a power supply. The power supply provides power to variouscomponents of the computing devices 114, 116, 118, 120. The power supplymay include one or more rechargeable, disposable, or hardwire sources,e.g., batteries, power cord, AC/DC inverter, DC/DC converter, or thelike. Additionally, the power supply may include one or more types ofconnectors or components that provide different types of power to thecomputing devices and/or servers 114, 116, 118, 120. In someembodiments, the power supply may include a connector (such as auniversal serial bus) that provides power to the computer or batterieswithin the computer and also transmits data to and from the device toother devices.

The input/output interface 804 allows the computing devices and/orservers 11 to receive input from a user and provide output to the user.For example, the input/output interface 804 may include a capacitivetouch screen, keyboard, mouse, stylus, or the like. The type of devicesthat interact via the input/output interface 804 may be varied asdesired. It should be noted that the various computing devices may be incommunication with a compute back end, such as the server or a cloudprovider, e.g., Google Cloud Platform, Amazon Web Services, MicrosoftAzure, or the like.

The foregoing description, for purposes of explanation, uses specificnomenclature to provide a thorough understanding of the describedembodiments. However, it will be apparent to one skilled in the art thatthe specific details are not required to practice the describedembodiments. Thus, the foregoing descriptions of the specificembodiments described herein are presented for purposes of illustrationand description. They are not targeted to be exhaustive or to limit theembodiments to the precise forms disclosed. It will be apparent to oneof ordinary skill in the art that many modifications and variations arepossible in view of the above teachings.

What is claimed is:
 1. A method for execution of application codedeveloped using a simplified programming interface comprising:designating input/output (I/O) tasks and processing intensive tasks asevent callbacks in a single event loop runtime environment, wherein theI/O tasks and processing intensive tasks are generated in associationwith a user request to execute the application code; offloading tasksassociated with the event callbacks to a task queue including I/O tasksand processing intensive tasks for execution using a resource basedmultithreading module to allocate the tasks in the task queue between aplurality of processors based on current utilization of each of theplurality of processors and an estimation of computing resources forexecution of the tasks, wherein the resource based multithreading moduleis separate from the single event loop runtime environment; executingthe tasks at the allocated processors of the plurality of processors;and fulfilling the user request using results of the executed tasks. 2.The method of claim 1, further comprising: identifying the I/O tasks andthe processing intensive tasks from a plurality of received executabletasks using predefined task information.
 3. The method of claim 1,wherein the estimation of computing resources used in execution of thetasks is generated using at least historical data about execution ofsimilar tasks.
 4. The method of claim 3, further comprising: reportingan actual amount of computing resources used by the allocated processorsof the plurality of processors in executing the tasks; and updating thehistorical data about execution of similar tasks based on the reportedactual amount of computing resources used by the allocated processors ofthe plurality of processors in executing the tasks.
 5. The method ofclaim 1, wherein the plurality of processors are associated with aplurality of threads.
 6. The method of claim 5, wherein offloading tasksassociated with the event callbacks for execution further comprises:identifying one or more processors in the plurality of processorsassociated with at least one thread that is free to execute a task; anddetermining a current level of resource use for each of the identifiedone or more processors.
 7. The method of claim 6, further comprising:for a first task of the offloaded tasks, identifying availableprocessors of the identified one or more processors, wherein theavailable processors have enough free resources to execute the taskbased on the estimation of computing resources for execution of thetask; and allocating the first task to a processor of the availableprocessors, wherein a difference between the available computingresources of the processor and the estimation of computing resources forexecution of the first task is smaller than a difference between theavailable computing resources of at least one of the other availableprocessors and the estimation of computing resources for execution ofthe first task.
 8. The method of claim 6, further comprising: for a taskof the offloaded tasks, identifying the task as an I/O task; andallocating the task to a processor of the identified one or moreprocessors, wherein the processor has a highest current level ofcomputing resources of the identified one or more processors.
 9. Acomputing system for executing a task allocation agnostic applicationcode comprising: a plurality of processors; an application engineexecuting on the plurality of processors, the application enginecomprising: an interpreter configured to identify an input/output (I/O)task or a processor intensive task as an intensive task from a pluralityof tasks in the task allocation agnostic application code correspondingto a received request from a user, the identification based on anestimation of computing resources for execution of the intensive task; aruntime environment comprising: a call stack configured to execute thetasks of the application code, wherein the call stack executes taskssequentially as a task reaches an execution position within the callstack; and a resource based multithreading module executing on theplurality of processors, the resource based multithreading modulecomprising: a task queue configured to remove the intensive task fromthe call stack as the intensive task reaches the execution position, thetask queue including both I/O tasks and processor intensive tasks ascheduler configured to allocate the intensive task to a processor ofthe plurality of processors based on the estimation of computingresources for execution of the intensive task and a current utilizationof each of the plurality of processors, wherein the processor executesthe allocated intensive task to obtain a result of the intensive task,and an interface configured to return the result of the intensive taskto the runtime environment, wherein the runtime environment isconfigured to return the result of the intensive task to the call stackand use the result of the intensive task in completing the request ofthe user when the result of the intensive task reaches the executionposition.
 10. The computing system of claim 9, wherein the runtimeenvironment further comprises: a callback queue; and an event loopconfigured to control movement of callbacks from the callback queue tothe call stack.
 11. The computing system of claim 10, wherein thescheduler is further configured to: receive a result of the executedintensive task from the assigned processor; and return the result to thecallback queue of the runtime environment.
 12. A method for allocatingan intensive task in an application code developed using a programminginterface to a processor for execution, the method being obscured fromthe programming interface and comprising: accessing the intensive taskin a task queue comprising input/output (I/O) tasks and processingintensive tasks received from a JavaScript runtime environment as aresult of a received user request to execute the application code;determining an estimation of computing resources for execution of theintensive task; allocating the intensive task to one of a plurality ofprocessors based on a current utilization of each of the plurality ofprocessors and the determined estimation of computing resources forexecution of the intensive task; processing the task at the allocatedprocessor; and returning the processed task to the JavaScript runtimeenvironment as a callback, wherein the JavaScript runtime environmentuses the processed task in completing the user request.
 13. The methodof claim 12, further comprising: identifying the intensive tasks from aplurality of tasks identified from the application code in response toreceipt of the user request.
 14. The method of claim 13, wherein thecode is graphical code including functional modules and connectors,wherein the functional modules and connectors are associated withunderlying source code.
 15. The method of claim 14 wherein at least onefunctional module of the graphical code defines one of a machinelearning operation and an artificial intelligence operation.
 16. Themethod of claim 14, wherein the functional modules further includepre-defined intensive tasks.
 17. The method of claim 12, furthercomprising: returning a response to the user request to a user device.18. The method of claim 12, wherein the estimation of computingresources for one of the intensive tasks is determined based onhistorical data about the execution of intensive tasks.
 19. The methodof claim 18, further comprising: updating the historical data about theexecution of intensive tasks based on actual computing resources usedfor the task, wherein the processed task is returned to the JavaScriptruntime environment with an indication of the actual computing resourcesused for the task.
 20. The method of claim 19, wherein the intensivetask is a processor intensive task, wherein the processor intensive taskuses more than a threshold amount of computing resources.